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1.0    Introduction 

The  primary  purpose  of  this  study  was  to  develop  a  standard  format 
for  the  specification  of  algorithms  .    While  a  number  of  standards  exist 
for  so-called  algorithm  specification,   (e.g.  ACM's  Algorithm  Policy, 
CACM  14(1971)    676}  ,  in  fact  those  standards  are  for  programs,  algorithms 
which  have  been  implemented  in  a  particular  language  or  for  a  particular 
computer. 

It  was  desired  to  have  a  standard  specification  from  which  the  algor- 
ithm can  be  easily  implemented  and  from  which  a  prospective  user  could 
decide  within  certain  limits  ,  whether  a  given  algorithm  meets  his  require- 
ments before  actual  implementation  on  his  hardware.    Alternatively  the 
algorithm  specification  should  be  able  to  help  the  potential  user  decide 
upon  what  hardware  would  be  required  to  solve  his  problem.    It  is  clear, 
then,  that  we  wish  to  keep  the  specification  of  the  algorithm  independent 
of  any  particular  programming  language  or  any  computer.    While  this  is 
desirable  from  the  standpoint  of    the  user  who  is  in  the  process  of  choosing 
hardware,  it  is  more  difficult  for  the  algorithm  specification  to  be  written, 
and  some  information  which  it  is  desirable  to  know  cannot  be  given  in 
this  generality. 

A  number  of  investigations  into  methods  of  specifying  algorithms  have 
been  made ,  and  we  will  mention  some  of  them  briefly . 

D.  L.  Parnas  [11]     has  suggested  an  algol-like  language  which  is 
designed  to  convey  to  the  user  and  the  implementer  alike  exactly  that 
information  he  needs  and  no  more.    In  addition,  the  specification  is  de- 
signed so  that  it  is  possible  to  machine  test  it  for  completeness  and  con- 
sistency.   The  author  notes  that  the  technique  has  been  met  with  some 
resistance  and  initial  failures,  although  it  "is  eventually  mastered  by 
almost  everyone."    This  writer  certainly  believes  the  first  part  of  that 
statement  and  feels  that  the  information  conveyed  about  what  function  is 
performed  by  the  algorithm  is  too  sparse. 


In  the  examples  it  is  quite  unclear  what  is  being  done,  although 
perhaps  this  is  in  line  with  the  stated  intent  of  the  author  concerning  the 
information  to  be  conveyed  .    The  goal  of  minimal  information  about  the 
structure  of  connecting  modules  ,  and  the  possibility  of  machine  testing 
for  completeness  and  consistency  are  certainly  desirable  and  further 
development  may  yieid  better  methods  . 

The  specification  of  algorithms  in  terms  of  a  set  language  has  been 
treated  by  several  authors,  e.g.  [4]  ,  [14]  .    While  these  abstract 
languages  have  desirable  properties,  particularly  in  terms  of  precision, 
as  Schwartz  [14]    notes  they  do  not  give  as  clear  an  explanation  of  the 
algorithm  as  a  natural  language  description „    This  occurs  in  an  elusive, 
but  still  real,  sense. 

The  use  of  flow  charts   |l6]    and  D-charts  [1]    have  been  discussed 
also.    While  flow  charts  are  familiar  to  nearly  everyone,  and  can  be 
used  to  completely  specify  the  flow  of  control  in  the  algorithm,  some 
important  information  is  suppressed  by  them.    In  particular,  a  flow  chart 
can  show  only  one  of  perhaps  many  equivalent  implementations  of  an 
algorithm.    Possible  parallelism  and  much  of  the  data  dependencies  are 
obscured . 

Several  attempts  have  been  made  to  develop  methods  which  overcome 
the  problems  inherent  in  flow  charts  .    Those  methods  take  the  form  of 
directed  graphs  and  are  generally  descendents  of  Petri  nets  [5]  ,  [15]  . 
The  most  elegant  of  these  appears  to  be  the  data  flow  language  of  Dennis 
and  Fosseen  [  2]  ,  although  a  number  of  earlier  versions  are  included  in 
the  bibliography.    The  data  flow  language  has  the  desirable  property  of 
showing  the  fiow  of  the  data  and  is  particularly  useful  in  blocks  where 
there  are  no  iteration  loops  and  no  branching  is  required.    A  partial 
ordering  on  the  sequence  of  operations  is  automatically  induced,  and 
possible  parallelism  is  exposed.    In  addition,  data  dependencies  are 


clearly  shown  which  is  helpful  in  the  partitioning  problem,  although  that 
is  not  our  principal  interest.    The  inclusion  of  control  links  in  the  rep- 
resentation, necessary  to  show  iteration  loops  and  branching,  clouds 
the  picture  considerably.    For  all  but  the  simplest  algorithms,  the  repre- 
sentation becomes  quite  clumsy,  making  it  fairly  difficult  to  specify  the 
algorithm  and  more  difficult  to  understand  it .    At  a  point  where  it  would 
conceivably  be  possible  for  the  language  to  be  compiled  by  a  computer, 
it  could  very  well  become  quite  valuable.    Studies  are  being  made  toward 
a  computer  which  could  implement  algorithms  in  this  way  [  3]   . 

It  is  recognized  that  it  is  desirable  to  specify  algorithms  in  a  non- 
redundant  manner,  and  in  a  way  which  is  capable  of  being  machine 
processed  for  completeness  and  consistency.    At  this  time  it  is  felt  that 
there  is  no  method  which  meets  all  desirable  requirements  .    Because  of 
the  distinct  sets  of  persons  who  would  be  looking  at  the  specification,  in 
particular  the  prospective  user  and  the  implementer ,  it  is  almost  a 
necessity  that  the  information  be  somewhat  redundant  or  that  the  interests 
of  one  of  the  two  groups  be  treated  more  lightly  than  the  other.    Addition- 
ally while  flow  graphs  or  flow  charts  serve  to  specify  the  algorithm  for  the 
implementer' s  purposes,  as  do  the  mathematical  equations  or  natural 
language  descriptions,  the  sets  of  information  in  those  two  items  serve 
to  complement  each  other  to  a  greater  degree  than  their  redundancy  de- 
tracts from  them.    One  reason  for  avoiding  redundancy  is  that  it  allows  the 
possibility  of  contradictions,  which  must  not  be  allowed  to  occur  without 
a  method  of  resolving  them.    Even  then  it  is  not  a  desirable  situation. 

Because  of  the  shortcomings  of  most  new  methods  proposed  for  al- 
gorithm specification,  we  have  attempted  to  maintain  a  somewhat  conven- 
tional method  of  algorithm  specification,   while  incorporating  the  best 
features  of  some  new  ideas  .    Further  development  in  any  of  several  possible 
directions  may  lead  to  new  methods  more  suited  to  our  purposes  and  we  must 
certainly  be  alert  to  any  such  development. 
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2  .0    The  Format  of  the  Proposed  Specification 

The  specification  of  the  algorithm  will  be  in  two  parts,  for  our 
purposes  .    Those  items  in  Section  1  will  be  mainly  of  interest  to  the  user. 
Section  2  will,  be  devoted  to  information  needed  by  the  implementer.    After 
implementation,  the  program  documentation  will  give  information  concerning 
storage  requirements  and  timing  which  will  be  of  interest  to  the  user.    In 
effect,  this  documentation  will  form  a  Section  3.    There  will  be  a  differ- 
ent documentation  for  each  implementation  (different  language  or  dif- 
ferent computer)  .    We  will  not  concern  ourselves  with  the  exact  form  of 
the  documentation,  but  it  will  consist  primarily  of  the  exact  method  of 
communication  with  the  calling  program,  and  memory  and  timing  require- 
ments .    The  implementation    must  conform  to  the  specification  in  Sec- 
tions 1  and  2  with  no  exceptions  or  else  it  cannot  be  considered  to  be  an 
implementation  of  that  algorithm  . 

The  description  of  the  various  sections  in  the  algorithm  specification 
and  the  information  they  are  to  convey  follows  in  Section  2  .1. 
2  .1    The  Algorithm  Specification 

1.0    Background  Information  and  General  Description 

This  section  will  contain  information  about  where  the  algorithm  is 

used  and  a  brief  description  of  what  the  algorithm  accomplishes  . 

The  information  given  should  be  sufficient  to  allow  the  user  to  de- 
termine whether  the  algorithm  is  of  interest  to  him  without  giving 

unnecessary  details  . 

l.i    Other  Algorithms  Used 

This  section  will  contain  a  listing  of  other  algorithms  used  by  the 

subject  algorithm. 

1 .2    Input  Values 

This  section  will  contain  a  description  of  the  values  which  are 

input  to  the  algorithm  .    These  must  be  described  in  terms  of  units 
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(where  required;  sometimes  the  input  units  needn't  be  specified 
and  output  units  are  the  same  as  input  units)  ,  reference  lines 
or  angles,  which  direction  is  positive,  and  so  on.    Any  assumptions 
concerning  the  range  in  which  the  inputs  must  lie  should  be  de- 
lineated .    This,  in  conjunction  with  possible  error  indications 
(see  Section  1.3)  will  convey  to  the  user  the  possible  need  for  pre- 
processing of  arguments  by  the  calling  program. 

1.3  Output  Values  and  Accuracy 

The  values  which  are  output  from  the  algorithm  are  described  in 
this  section.    Information  about  the  accuracy  of  the  output  values 
should  assume  the  inputs  are  exact,  even  though  in  the  usual  instance 
this  will  not  be  true.    Given  in  this  fashion,  though,  and  given 
information  about  the  accuracy  of  the  input  values  ,  one  can  determine 
limits  on  the  error  propogated  through  the  algorithm.    When  necessary, 
the  units  ,  reference  lines  or  angles  ,  positive  directions  ,  and  other 
data  must  be  specified  as  they  are  for  input.    Possible  output  values 
include  error  indications  and  potential  error  flags  should  be  fully 
described . 

1.4  Operation  Count 

The  precise  timing  for  an  algorithm  is  available  only  after  the 
choice  of  implementation  has  been  made.    However,  some  useful 
information  can  be  given  in  terms  of  the  number  of  operations  of 
different  type  which  occur  and  the  number  of  references  to  external 
routines  (other  algorithms)  .    Thus  it  will  be  possible  to  give  the 
user  a  rough  estimate  of  the  execution  time  in  terms  of  the  operations 
required  .    This  estimate  will  be  most  accurate  when  large  numbers  of 
arithmetic  instructions  are  required  for  which  the  time  can  be  esti- 
mated with  some  accuracy.     In  other  instances  the  count  may  be 
highly  dependent  on  the  instruction  repertoire  of  the  computer,  and 
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2  .0    The  Format  of  the  Proposed  Specification 

The  specification  of  the  algorithm  will  be  in  two  parts,  for  our 
purposes  .    Those  items  in  Section  1  will  be  mainly  of  interest  to  the  user. 
Section  2  will  be  devoted  to  information  needed  by  the  implementer.    After 
implementation,  the  program  documentation  will  give  information  concerning 
storage  requirements  and  timing  which  will  be  of  interest  to  the  user. 
In  effect,  this  documentation  will  form  a  Section  3.    There  will  be  a  dif- 
ferent documentation  for  each  implementation  (different  language  or 
different  computer)  .    We  will  not  concern  ourselves  with  the  exact  form  of 
the  documentation,  but  it  will  consist  primarily  of  the  exact  method  of 
communication  with  the  calling  program,  and  memory  and  timing  require- 
ments .    The  implementation  must  conform  to  the  specification  in  Sections 
1  and  2  with  no  exceptions  or  else  it  cannot  be  considered  to  be  an  im- 
plementation of  that  algorithm  . 

The  description  of  the  various  sections  in  the  algorithm  specifica- 
tion and  the  information  they  are  to  convey  follows  in  Section  2.1. 

2.1  The  Algorithm  Specification 

1.0    Background  Information  and  General  Description 

This  section  will  contain  information  about  where  the  algorithm 
is  used  and  a  brief  description  of  what  the  algorithm  accomplishes  . 
The  information  given  should  be  sufficient  to  allow  the  user  to  deter- 
mine whether  the  algorithm  is  of  interest  to  him  without  giving  unneces- 
sary details  . 
1.1    Other  Algorithms  Used 

This  section  will  contain  a  listing  of  other  algorithms  used  by  the 
subject  algorithm. 

1 .2  Input  Values 

This  section  will  contain  a  description  of  the  values  which  are 
input  to  the  algorithm.    These  must  be  described  in  terms  of  units 
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hence  only  a  poor  estimate  can  be  given  before  implementation. 
In  any  case  trie  estimate  will  not  include  overhead  and  should  be 
interpreted  in  that  light. 

1.5    Memory  Requirements 

This  section,  like  the  previous  one,  cannot  be  made  very 
precise.    In  particular,  the  program  length  cannot  be  estimated 
without  knowing  the  instruction  repertoire  of  the  computer  on 
which  the  algorithm  is  implemented.    However,  this  section  can 
contain  information  concerning  the  number  of  constants  required 
and  the  number  of  temporary  storage  locations  required  by  the  al- 
gorithm . 
2  .0    Mathematical  and  Natural  Language  Description 

This  section  gives  a  full  description  of  the  algorithm  in  terms 
of  the  mathematic  equations,  if  any,  and  the  necessary  natural 
language  descriptions  necessary  to  make  clear  the  functions  per- 
formed by  the  algorithm.    The  definition  of  each  variable  should  be 
given.    For  algorithms  with  many  variables  a  list  should  be  given 
as  this  would  facilitate  finding  the  definitions  easily.    If  possible, 
the  range  of  values  which  may  be  taken  on  by  each  variable  should 
be  specified.    One  must  at  least  specify  whether  the  values  taken 
on  are  integers  ,  real  numbers  ,  complex  numbers ,  or  logical  values  . 
2  .1    Flow  Diagrams 

The  flow  diagrams  may  consist  of  two  types  .    When  the  algorithm 
involves  iterations  or  a  large  number  of  decisions  ,  a  conventional 
flow  chart  is  probably  best  since  in  this  case  the  flow  of  control 
is  most  important.    When  only  a  few  decisions  are  required,  or  none, 
the  use  of  a  process  graph  is  desirable  since  it  exposes  many 
features  of  which  the  implementer  should  be  aware. 

The  type  of  process  graph  we  generally  have  in  mind  is  similar 


to  the  data  flow  graph  of  Dennis  and  Fosseen  [  2]  when  there  are 
no  decisions  to  be  shown.  We  will  briefly  discuss  the  elements 
and  structure  of  the  process  graph  as  we  intend  it  to  be  used. 

The  process  graph  consists  of  computational  biocks  ,  each 
of  which  may  be  as  complex  (a  subalgorithm)  or  as  simple  (a  single 
operation)  as  one  likes  or  finds  necessary.    These  blocks  are  con- 
nected by  directed  line  segments  to  form  a  directed  graph.    The  line 
segments  show  the  flow  of  data  through  the  graph.    Input  values  to 
a  computational  block  are  shown  as  labeled  line  segments  directed 
toward  the  block .    The  computations  in  a  block  may  be  performed 
as  soon  as  all  input  values  are  available  .    Outputs  from  a  block  are 
shown  by  labeled  line  segments  directed  away  from  the  block. 
Input  values  which  are  not  output  values  from  another  block  are  in- 
puts to  the  algorithm,  except  for  constants  which  are  shown  arising 
from  disks  .    Output  values  which  are  not  input  values  for  another 
block  are  outputs  from  the  algorithm.    Process  graphs  are  in  many 
ways  reminiscent  of  signal  flow  graphs  [8]  ,  although  process 
graphs  have  no  feedback  and  involve  more  complicated  operations  . 
A  similar  type  of  graph  has  previously  been  used  to  describe  com- 
plicated weapon   systems,  e.g.  [8]  .    In  addition  to  their  utility 
in  determining  data  dependencies  ,  a  partial  ordering  of  operations , 
and  potential  parallelism,  process  graphs  can  also  be  utilized  to 
determine  error  bounds  for  a  set  of  calculations  .    They  are  used 
primarily  for  this  purpose,  in  a  slightly  different  form,  by 
McCracken  and  Dorn  [  9]   . 

We  propose  that  the  type  of  flow  diagram  provided  for  a  given 
algorithm  should  be  an  option  of  the  specification  writer.    In  some 
instances  one  of  the  two  types,  flow  chart  or  process  graph,  may 
be  more    appropriate.  In  other  instances  it  may  be  useful  to  include 
both  a  flow  chart  and  a  process  graph.    This  leads  to  a  possible 
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difficulty  in  that  a  flow  chart  yields  a  complete  ordering  on  the 
operations    performed,  whereas  a  process  chart  ordinarily  yields 
only  a  partial  ordering.    Some  algorithms  may  be  best  described 
by  a  process  graph  involving   computational  blocks  with  decisions 
and  iterations  imbedded  in  them.    These  computational  blocks 
might  be  best  described  by  flow  charts  .    Or  the  reverse  may  be 
better  in  some  instances  ,  although  the  flow  of  the  data  would 
seem  to  be  somewhat  obscured  by  the  use  of  an  overall  flow  chart. 
2.2    Other 

When  the  algorithm  specification  is  being  written  it  may  be 
necessary  to  make  certain  assumptions  about  number  representa- 
tion or  other  details  which  may  vary  for  some  implementations  , 
but  have  no  profound  effect  on  the  algorithm.    In  this  section  such 
variations  and  their  effect  on  the  implementation  should  be  pointed 
out . 
2  .3    References 

This  section  contains  a  list  of  all  books,  reports,  journal 
articles  and  other  items  which  may  be  referenced  for  additional 
information . 
3.0    Some  Algorithms 

The  following  examples  are  intended  to  illustrate  the  proposed 
method  of  algorithm  specification.    While  not  all  types  of  algorithms 
are  included,  among  them  are  purely  a  computational  algorithm,  a 
purely  manipulative  algorithm,  and  several  floating  point  algorithms 
which  involve  a  number  of  tests  and  shifts  as  well  as  a  few   arithmetic 
operations  . 
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I.    Coordinate  Rotation:    Airframe  to  Earth  Coordinates 

1.0  Background  Information  and  General  Discussion 

The  purpose  of  this  algorithm  is  to  convert  the  coordinates  of 
a  radar  target  or  other  object  given  in  airframe  coordinates  to  earth  co- 
ordinates . 

1.1  Other  Algorithms  Used 

This  algorithm  uses  the  sine  and  cosine  algorithms  . 

1 .2  Input  Values 

The  input  values  to  this  routine  are  the  coordinates  of  the 
target  with  respect  to  the  airframe,  and  the  heading,  pitch  angle,  and 
roll  angle  of  the  airframe.    All  input  values  are  real  numbers  .    It  is  as- 
sumed that  the  heading,  pitch  angle,  and  roll  angle  are  given  in  degrees  . 
The  heading,     ty    normally  lies  in  the  range  [0,360    ]  ,  while  the  pitch 
angle,     Q     and  the  roll  angle,  0      lie  in  the  range  [-180      ,  180]     .    No 
error  occurs  for  angles  outside  this  range,  A  due  north  heading  is  zero, 
while  easterly  headings  are  positive.    Pitch  angles  are  positive  nose  up, 
and  roll  angles  are  positive  right  wing  down. 

1.3  Output  Values  and  Accuracy 

The  output  values  are  the  earth  coordinates  of  the  target  with 
respect  to  the  position  of  the  airframe.    Output  units  are  the  same  as 
the  input  units  .    The  positive  directions  for  the  output  coordinates  are 
north,  east,  and  down,  respectively. 

The  accuracy  of  the  results  depens  on  the  accuracy  of  the  sine/ 
cosine  algorithm  and  could  be  as  large  as  about  7  or  8  times  the  error 
in  that  algorithm,  relative  to  the  largest  of  the  airframe  coordinates  . 
The  usual  error  will  be  much  smaller,  perhaps  one  or  two  bits  compared 
to  the  largest  of  the  airframe  coordinates  . 
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1.4  Operation  Count 

The  algorithm  requires  six  sine/cosine  evaluations,  2  6  multipli- 
cations, and  10  additions  which  should  dominate  the  total  execution  time. 

1.5  Memory  Requirements 

This  routine  requires  about  ten  temporary  storage  locations  ,  one 

constant,  and  locations  for  any  registers  that  must  be  saved. 

2  .0    Mathematical  and  Natural  Language  Description 

Let    x     -  y     -  z      be  a  right  hand  orthogonal  coordinate  system 
a        a        a 

associated  with  the  airframe,    x      is  positive  forward  along  the  airframe 

a 

center  line,     y      is  positive  out  the  right  wing,  and    z      is  positive 
a  a 

downward.    Let    x     ,    y     ,    and    z      representtheairframecoordinat.es  of 

a  a  a 

the  target.    Let    ij-    be  the  airframe  heading  with  respect  to  true  north, 
9    the  airframe  pitch  angle-positive  upward,  and    0    the  airframe  roll  angle 
positive  right  wing  down  „    Then  the  target  position  in  earth  coordinates  is 
given  by  a  rotation  of  the  position  in  airframe  coordinates,  represented  by 
the  matrix  multiplication 


Dl. 

D12 

D13 

D21 

D22 

D2  3 

D31 

D32 

D33 

.      Here    T     ,    T      and    T 
\al  x  y  z 

are  the  north,  east,  and  down  components  of  the  earth  coordinates,  re- 
spectively.   The  matrix  elements  are  given  by 

D  =  cos    ty  cos  e 

D  =  sin    0  sin    fi   cos  ^  -  sin  -;      cos  0 

D  =  sin  0  sin    tir   +    cos  8     cos  •!; 

D   .  =  cos  9  sin  jf 

D  =  cos  0  cos  ijf  +    sin  0     sin    n     sin  ty 

D  =  cos  0  sin    6    sin    J,  -  sin   0     cos  ^ 

D31  =  sin  e 

D  =  sin  0  cos  e 

D  =  cos  0  cos  9 
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2.1    Flow  Diagram 
2.1.1  Process  Graph 
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None 
2  .3    References 

See  Bibliography  [12] 
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II.    Coordinate  Conversion:    Spherical  to  Cartesian  Coordinates 

1.    Background  Information  and  General  Discussion 

The  purpose  of  this  algorithm  is  to  convert  the  given  spherical 
coordinates  of  a  point  in  three  space  to  the  corresponding  cartesian  co- 
ordinates . 

1„1    Other  Algorithms  Used 

The  sine/cosine  algorithm  is  used  by  this  algorithm  0 
1  „2    Input  Values 

The  input  values  are  the  spherical  coordinates,     (p  t  &  ,  &)    of  a 
given  point,  which  are  real  numbers  .    Here    p    is  the  distance  of  the 
point  from  the  pole,  or  origin,    0    is  the  angle  the  radius  vector  makes 
with  the  z-axis  ,  and    9    is  the  angle  the  projection  of  the  radius  vector 
into  the  x-y  plane  makes  with  the  x-axis ,  measured  positive  counter- 
clockwise.   Angles  are  measured  in  radians  „ 

The  figure  shows  the  relationship  for  a  typical  point    P   . 


(p,<M) 

( (x,y,z) 
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1.3    Output  Values  and  Accuracy 

The  output  values  are  the    x,  yt    and    z    coordinates  of  the  given 
point o    The  units  are  the  same  as  those  of  the  input    P  .    The  error  in  the 
coordinates ,  relative  to    D  ,    would  be  no  more  than  twice  the  error  in  the 
sine/cosine  algorithm  0 
lc4    Operation  Count 

This  algorithm  requires  four  sine/cosine  evaluations  and  four 
multiplications  0 

105    Memory  Requirements 

Approximately  four  locations  are  required  for  temporary  storage 
plus  any  locations  required  for  storage  of  registers  „ 

2  oO    Mathematical  and  Natural  Language  Description 

The  equations  relating  spherical  coordinates  (  p  „  $„   g)    and 
cartesian  coordinates    (xe  y c  z)    are 
x    =      p    sin    0    cos     G 
y    =      p    sin    0    cos    0 
z     =       p    cos     0   o 
p  t    0  c    and     6    are  real  numbers  and  ordinarily    p    ^   0 1 
0^0     <,     -ft*    and    0     <      Q    <    2tt  „    although  these  restrictions  are  not 
necessary  for  proper  operation  of  the  algorithm  0 
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2.1    Flow  Diagram 
2.1.1  Process  Graph 
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2.2  Other 
None 

2.3  References 
None 
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III.    Radar  Target  Processing 

1.0    Background  Information  and  General  Description 

The  purpose  of  the  algorithm  is  to  convert  the  radar  outputs  of 
range,  bearing,  and  elevation  with  respect  to  airframe  coordinates  to 
earth  coordinates  . 

1.1    Other  Algorithms  Used 

The  spherical  to  cartesian  coordinate  conversion  algorithm  (II)  and 
the  coordinate  rotation  algorithm  (I)  are  used0 

1 .2  Input  Values 

The  input  values  to  the  algorithm  are  the  radar  outputs  of  range, 

bearing,  and  elevation,  and  the  airframe  heading,  pitch  angle,  and  roll 

angle.    All  angles  are  in  degrees  .    Positive  directions  for  the  airframe  are 

as  described  in  algorithm  I.    Target  bearing  is  measured  from  the  airframe 

x     -  z      plane,  positive  clockwise  when  viewed  from  above.    Elevation  is 
a        a 

positive  upward  with  respect  to  the  airframe    x     -  y      plane. 

a        a 

1.3  Output  Values 

The  output  values  are  the  earth  coordinates  of  the  target  with 
respect  to  the  airframe  position,  in  northerly,  easterly,  and  downward  com- 
ponents .    The  units  are  the  same  as  those  of  the  input  range.    The  error 
in  the  output  values  is  no  greater  than  the    sum  of  the  errors  in  the  algor- 
ithms I  and  II,  hence  the  error  is  no  greater  than  8  or  9  times  the  error  in 
the  sine/cosine  routine.    This  is  the  error  measured  relative  to  the  input 
value  of  range,    In  the  usual  case  the  error  should  be  about  one  or  two 
bits,  relative  to  the  range. 

1 .4  Operation  Count 

The  algorithm  requires  two  additions  and  two  multiplications  for 
argument  processing  before  one  transfer  to  each  of  the  algorithms  men- 
tioned in  section  1.1. 
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1.5    Memory  Requirements 

Two  constants  are  required  by  the  algorithm. 

2  .0    Mathematical  and  Natural  Language  Description 

Let    x   ,  y   ,  z    ,    be  the  axes  of  an  orthogonal  coordinate  sys- 
a       a       a 

tern  associated  with  the  airframe,    x      is    positive  forward  along  the  air- 

a 

frame  center  line,     y      is  positive  out  the  right  wing  and    z      is  positive 

a  a 

downward.    Let    R      be  the  slant  range  to  the  target,    t\     the  target 

elevation  with  respect  to  the    x     -  y      plane-positive  upward,  and    ij; 

a         a  t 

the  target  bearing  with  respect  to  the    x     -  z      plane-positive  clockwise 

a        a 

when  viewed  from  above  0    Then  the  spherical  coordinates  of  the  target 
are    (R    ,  0,  9)    ,  where    0  =    90  +   e      and       @  =    90     "  4.  • 

o  L  L 

The  angles  are  assumed  to  be  in  degrees  and  are  converted  to 
radians  before  entry  to  the  spherical  to  cartesian  coordinate  conversion 
algorithm.    The  airframe  coordinates  are  then  converted  to  earth  co- 
ordinates using  algorithm  I. 
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2.1    Flow  Diagram 
2.1.1  Process  Graph 


Spherical-Cartesian  Coordinates 
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2.2    Other 

None 
2  „3     References 

See  Bibliography  [12] 
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IV.    Floating  Point    Multiplication 

1.0  Background  Information  and  General  Description 

The  purpose  of  this  algorithm  is  to  obtain  the  product  of  two 
numbers  represented  in  floating  point  format  on  a  computer  which  does 
not  have  floating  point  hardware.    It  is  assumed  the  computer  is  capable 
of  performing  fixed  point  additions  and  multiplications  . 

1.1  Other  Algorithms  Used 

No  other  algorithms  are  used  by  the  floating  poing  multiply. 

1 .2  Input  Values 

The  input  values  are  the  two  operands  expressed  in  floating 
point  format . 

1.3  Output  Values  and  Accuracy 

The  output  value  is  the  product  of  the  operands  expressed  in 
floating  point  format.    The  output  valve  is  in  normalized  form  provided 
the  input  values  are  in  normalized  form  (no  leading  zero  digits)  „    If 
the  characteristic  of  the  product  exceeds  the  maximum  allowable,  an 
overflow  is  indicated  and  the  characteristic    is  set  to  the  maximum 
number  which  can  be  represented.    The  result  is  accurate  to  +_  -|    in  the 
least  significant  digit  of  the  mantissa  . 

1 .4  Operation  Count 

The  number  of  operations  depends  on  the  instruction  repertoire 
of  the  computer,  but  will  involve  one  multiplication,  one  addition,  and 
about  15  index  incrementation,  test,  compare,  shift,  and  logical  oper- 
ations . 

1.5  Memory  Requirements 

The  algorithm  requires  about  ten  locations  for  temporary  storage 
and  constants,  depending  on  how  the  arguments  are  transmitted  to  the 
algorithm  „ 
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2.0    Mathematical  and  Natural  Language  Description 

Let  the  two  operands  be  represented  by    A    and    R    .    Define    A 

m 

and    a    such  that    A  -    A    r      ,    where     r    is  the  base  of  the  number  system 

rrr  H 

used  by  the  computer,     A         is  the  mantissa ,  and    a    is  the  characteristic  „ 

m  -1 

We  assume    A       is  in  normalized  form  that  is     r      5;  {A     I  <    1    or    A      =    0    . 
m  m  a  +  p     m 

B       and    b    are  defined  analogously.    Because    AB  =    A    B      r  the 

m  m   m  w 

algorithm  multiplies  mantissae,  adds  characteristics,  normalizes  the 
product  of  the  mantissae,  rounds  and  renormalizes  the  product  of  the  man- 
tissae.   Normalizations  are  done  under  the  assumption    A    and    B    were 
normalized.    If   A    or    B    are  not  normalized,  then  the  product  may  not  be 
normalized.    If  the  product  of  the  (unnormalized)  mantissae  has  more  than 
d  +   1    (d  =    number  of  significant  digits  in  the  mantissa  of  the  representa- 
tion) leading  zeros  ,  the  product  will  be  zero .    No  error  indication  occurs 
in  this  instance  „ 

If  overflow  occurs  the  characteristic  is  set  to  the  largest  value 
possible  and  an  overflow  indicator  is  set„ 
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2.1     Flow  Diagram 
2.1.1   Flow  Chart 
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2.1.2   Process  Graph 
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2.2    Other 

We  have  assumed  that  the  floating  point  representation  is  of  a 
particular  form,  i.e.,  the  mantissa  normalized  between    r       and    1   . 
Other  normalizations  are  possible,  in  particular  the  mantissa  might  be 
normalized  between    1    and    B  .    In  this  instance  the  procedure  for  norma- 
lization might  involve  a  right  shift  rather  than  a  left  shift  „ 

Another  slight  difference  which  can  occur  is  the  bias  of  the 
characteristic .    In  order  to  avoid  storing  negative  characteristics  ,  the 
value  stored  is  biased  by  a  positive  integer,     n  .    If    M    represents  the 
maximum  value  which  can  be  represented  by  the  digits  allowed  for  the 
characteristic,  the  approximate  range  of  numbers  which  can  be  represented 
is     3         to     g  o    Hence,     ct    is  often  chosen  to  be  near    M/2    „    In  any 

case,  if    a  /   0    the  bias  must  be  allowed  for  when  computing  the  charac- 
teristic    of  the  product. 

2  .3    References 
None 
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V.     Floating  Point  Addition 

1.0    Background  Information  and  General  Description 

The  purpose  of  this  algorithm  is  to  obtain  the  sum  of  numbers 
represented  in  floating  point  format  on  a  computer  which  does  not  have 
floating  point  hardware.  It  is  assumed  the  computer  can  perform  fixed 
point  additions  „ 

1.1  Other  Algorithms  Used 
None 

1 .2  Input  Values 

The  input  values  are  the  two  operands  expressed  in  floating  point 
format . 

103    Output  Values  and  Accuracy 

The  output  value  is  the  sum  of  the  two  input  values ,  expressed 

in  normalized  floating  point  format  „    The  output  value  is  accurate  to  +_  i 

th 

in  the  d       (least)  significant  digit  provided  the  input  values  are  in  norma- 
lized form.    Unnormalized  input  values  may  result  in  less  accuracy.    Under- 
flows (number  too  small  to  be  represented)  result  in  the  output  value  being 
set  to  zero,  while  overflows  (number  too  large  to  be  represented)  result  in 
the  output  value  being  set  to  the  largest  number  which  can  be  represented, 
with  the  appropriate  sign. 

1 .4  Operation  Count 

The  operation  count  depends  on  the  instruction  repertoire  of  the 
computer,  but  will  involve  between  3  and  3  -f    d  additions,  between  5  and 
5   +   d  tests,  and  a  similar  number  of  shifts  .    All  but  two  of  the  additions 
can  be  performed  as  index  increments  .    At  least  five  logical  operations 
will  be  required  . 

1.5  Memory  Requirements 

The  algorithm  requires  about  ten  locations  for  temporary  storage 
and  constants  . 
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2  .0    Mathematical  and  Natural  Language  Description 

Let    A    and    B    be  represented  in  floating  point  form .    Define    A 

a  -1  m 

and    a    such  that    A  =  A    g     ,  where    ?       <A      <  1    or    A      =    0   .    Here 

m  mm 

p    is  the  base  of  the  number  system  used  by  the  computer  „    B       and    b 
w  m 

are  defined  analogously.    Let    T    be  the  number  with  larger  exponent,  or 

either  one  if  they  have  the  same  exponent,  and  let    S    be  the  other.    Define 

T      .    t   .    S       and    s    as  above.    Then    s  ^t    and  the  tentative,  unrounded, 
mm 

mantissa  of   A  +    B    is    R  =    T      +   3     sS        .    IfR=0,C=A+B=0. 

m  rrr 

Otherwise     {r|     is  normalized,  rounded  to    d    digits,  and  renormalized 
if  necessary o    The  characteristic  of  the  sum  is  adjusted  as     JRJ     is  nor- 
malized, then  tested  for  underflow  or  overflow.    On  underflow,  the  output 
value  is  set  to  zero,  on  overflow  the  output  value  is  set  to  the  largest 
number  which  can  be  represented.    Finally  the  appropriate  sign  is  attached 
to  the  (nonzero)  result. 
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2. 1     Flow  Diagram 
2.1.1   Flow  Chart 
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2.2    Other 

Floating  point  number  representations  different  than  that  assumed 
are  possible,  e.g.  the  mantissa  normalized  to  lie  between    1    and     g   . 
In  this  instance  the  tests  for  normalization  may  be  slightly  different. 
2  . 3    References 
None 
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VI.    Floating  Point  Compare 

1.0    Background  Information  and  General  Description 

The  purpose  of  this  algorithm  is  to  compare  two  numbers  expressed 
in  floating  point  format  and  determine  if  they  are  equal,  or  which  is  larger 
if  they  are  not  equal . 

1.1  Other  Algorithms  Used 
None 

1 .2  Input  Values 

The  input  values  are  the  two  numbers    A    and    B    in  normalized 
floating  point  form . 

1.3  Output  Values  and  Accuracy 

The  output  value  is  an  integer  which  Lakes  on  the  following 
values: 

0  if     A  =    B 

1  if     A     >  B 
-]      if     A    <    B 

1.4  Operation  Count 

The  algorithm  may  include  as  many  as  4  tests  ,  5  logical  operations  , 
and  a  number  of  load  and  store  instructions  . 

1.5  Memory  Requirements 

Two  constants  are  required  and  up  to  four  temporary  storage  lo- 
cations ,  depending  of  the  number  of  registers  and  whether  they  must  be  saved 
2  .0    Mathematical  and  Natural  Language  Description 

Let    A    and    B    be  represented  in  normalized  floating    point  form  . 

Define    A  =    A       sa    where       g      <;    A     <lorA      r,    o    and     p   is  the  base 
m  mm 

of  the  number  system  used  by  the  computer.    B       and    b    are  analogously 

m 

defined.  If  A  and  B  have  opposite  sign  bits,  then  r  =  1  or  -1  as 
A  >  0  or  A  >  0  ,  respectively.  When  they  have  the  same  sign,  the 
characteristics  are  compared  and    r  =  <?    or    -c  as    a  >  b    or    a  <  b  , 
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where    3  -    !    or    -1    as    A    is  nonnegative  or  negative,  respectively.     If 

a  =    b  ,    the  mantis sae  are  compared  and    r  ■-    1 ,  0 ;    or    -1    as    A     >    B    , 

m  m 

A      =    B      ,    or   A     <    B      ,  respectively, 
mm  mm 
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2.1     Flow  Diagram 
2.1.1   Flow  Chart 
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2.2    Other 

None 
2  .3      References 

None 
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VII.       Memory  Rotate 

1.0  Background  Information  and  General  Discussion 

The  purpose  of  this  algorithm  is  to  rotate  the  contents  of  a 
table  in  memory  an  arbitrary  number  of  places  . 

1.1  Other  Algorithms  Used 
None 

1 .2  Input  Values 

The  input  values  are  the  tabular  array,  the  number  of  entries  in 
the  table,     n   ,  and  the  number  of  places  through  which  the  table  is  to  be 
rotated,    r   .     It  is  assumed  that    0    <    r    <    n   .     If    r    is  outside  this  range 
an  error  may  occur.    No  errors  are  indicated  when  this  occurs,  however. 

1.3  Output  Values  and  Accuracy 

The  output  values  are  the  rotated  tabular  array.     There  are  no 
error  indications  . 

1 .4  Operation  Count 

There  are  principally  three  types  of  operations  involved: 
(1)     index  incrementation,  of  which  there  are  between    2n  +    3    and 
3n  +    3;     (2)    tests ,  of  which  there  are  between    n  +    3    and    2n  +    3; 
and  (3)     load,  store,  and  register  exchange,  of  which  there  are  about 
n    each  .    The  total  number  of  operations  will  depend  on  the  number  of 
registers  available . 

1.5  Memory  Requirements 

No  more  than  five  temporary  storage  locations  should  be 

required  . 

2  .0    Mathematical  and  Natural  Language  Description 

Let  the  table  entries    x    ,  .  .  .  ,x      ,    be  stored  in  memory  loca- 

o  n-1 

tions     j  ,  i,  +   1  ,     i  +    2   ,  .  .  . ,      i  +    n-1   .    Then  the  algorithm  performs  the 
permutation  resulting  in     C(   j  +  j)   =    x    ,    where    j  =    (  i  -f    r)    mod    n  , 
i  =    0,2,...,  n-1   .      Here    C(k)     indicates  the  contents  of  location    k   . 
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2.1     Flow  Diagram 
2.1.1   Flow  Chart 
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2.2    Other 

None 
2  .3    References 

None 
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4  .0    Afterthoughts 

Some  difficulties  remain  which  must  ultimately  be  resolved,  and 
there  are  related  problems  which  have  not  been  discussed. 

In  some  instances    the  number  system  used  by  the  computer  may 
very  drastically  affect  the  algorithm  for  performing  certain  functions  . 
At  this  point  it  is  no  longer  possible  to  keep  the  algorithm  independent 
of  the  machine  architecture.     Perhaps  these  very  basic  algorithms 
should  be  considered  to  be  essentially  a  part  of  the  computer  and  not 
documented  in  the  same  fashion  as  higher  level  algorithms  .    The 
floating  point  algorithms  are  very  near  to  low  ievel  algorithms  in  that 
sense . 

In  a  hierarchy  of  algorithms  some  uniform  system  of  handling  errors 
must  be  used,  particularly  in  instances  where  there  must  be  no  crashes  , 
that  is  ,  some  reasonable  recovery  must  be  made  from  all  errors  .    This 
subject  has  not  been  discussed  previously,  but  it  seems  to  the  writer 
that  error  recovery  must  be  handled  at  a  point  as  near  to  the  discovery 
of  the  error  as  possible.    Related  problems  are  multiple  errors,  and 
the  problem  of  re-initialization  if  an  error  occurs  part  way  through  a 
computation.    That  is,  if  an  algorithm  updates  variables,  the  old 
value  must  not  be  lost  until  it  is  certain  the  calculation  can  be  completed 

The  problem  of  how  to  specify  recursive  functions  has  not  been  ex- 
plored, but  must  be  considered.    Likewise  the  problem  of  partitioning  a 
large  system  into  algorithms  which  will  be  useful  to  other  systems  (or 
already  used  by  other  systems)  must  be  considered  and  solved. 

The  weakest  link  in  any  specification  is  likely  to  be  the  individu- 
ality exhibited  by  the  person  writing  the  specification.     'Favorite' 
algorithms  are  likely  to  be  given  much  better  treatment  than  algorithms 
which  are  understood  poorly,  or  disliked  by  the  author.    In  other  in- 
stances ,  algorithms  thoroughly  understood  by  the  specifier  may  be  poorly 
written  because  they  are  so  'simple'  . 
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Those  tendencies  can  only  be  overcome  by  very  stringent 
guidelines  on  the  specification,  certainly  more  stringent  than  those 
proposed  in  Section  2.1. 


-  41  - 


Bibliography 


1.  John  Bruno  and  Kenneth  Steiglitz,   "The  Expression  of  Algorithms  by 

Charts,"    pp  97-115  in  Algorithm  Specification,  edited  by  Randall 
Rustin,   Prentice-Hall,  1972 

2.  Jack  B.  Dennis  and  John  B.  Fosseen,   "Introduction  to  Data  Flow 

Schemas,"    MIT  Project  MAC,  Computation  Structures  Group  Memo 
81-1,  September  1973 

3.  Jack  B.  Dennis  and  David  P.  Misunas  ,   "A  Preliminary  Architecture  for 

a  Basic  Data-Flow  Processor,"     pp  12  6-132  in  Proc  .  2nd  Annual 
Symposium  on  Computer  Architecture ,  1975 

4.  Malcolm  C.  Harrison,   "Declarative  and  Extendable  Languages," 

pp  39-60  in  Algorithm  Specification  t  edited  by  Randall  Rustin, 
Prentice-Hall,  1972 

5.  Anatol  W.  Holt,  et  al,   "Information  System  Theory  Project,"    RAC-TR-68- 

305,   (AD  676  972)  ,  Rome  Air  Development  Center,  September  19  68 

6.  Uno  R.    Kodres  and  William  L.  McCracken,   "Design  Study  of  an  Avionics 

Navigation  Microcomputer,"     pp  99-105  in  Proc.  2nd  Annual  Symposium 
on  Computer  Architecture,  1975 

7.  P.  R.  Kosinski,   "A  Data  Flow  Programming  Language,"    Report    RC  42  64 

IBM  T.J.  Watson  Research  Center,  Yorktown  Heights,  NY,  March  19  73 

8.  S.J.  Mason,   "Feedback  Theory-Some  Properties  of  Signal-Flow  Graphs," 

Proc.  IRE  41(1953)  1144-1156 

9.  D.J.  McCracken  and  W  .  S.  Dorn,  Numerical  Methods  and  Fortran 

Programming ,  Wiley,  19  64 

10  .  Naval  Air  Systems  Command  01-85  ADF-2-10  .1  ,  Integrated  Weapons  System 
Theory  for  A6E   Aircraft ,  1971 

11.  D.  L.  Parnas  ,   "A  Technique  for  Software  Module  Specification  with  Examples" 

CACM  15   (1972)    3  30-336 

12.  James  T.  Pepe  and  John  R.  Nestor  "Language  Bendmark  Tests,"    Draft 

Report,  Interrnetrics  ,  Inc.,  Cambridge  MA  02138  ,     August  1973 


-   42  - 


13.  J.E.  Rodriguez,    A    Graph  Model  for  Parallel  Computation  ,  "    Report 

TR-64,   Project  MAC,   MIT,  Sept    1969 

14.  Jacob  T.  Schwartz,   "Principles  of  Specification  Language  Design  with 

Some  Observations  Concerning  the  Utility  of  Specification  Languages  , " 
pp  1-37  in  Algorithm  Specification,  edited  by  Randall  Rustin,   Prentice- 
Hall,  1972 

15.  Robert  M  .  Shapiro,     et  al ,   "The  Representation  of  Algorithms "    RADC-TR- 

69-313,  Vol  II,   (AD  697026),  Rome  Air  Development  Center,  Sept  1969 

16.  H.  R.  Strong,   "Flowchartable  Recursive  Specification"     pp  81-96  in 

Algorithm  Specification,  edited  by  Randall  Rustin,  Prentice-Hall,  1972 


A3  - 


DISTRIBUTION  LIST 

No.  of  Copies 

Defense  Documentation  Center  2 

Cameron  Station 
Alexandria,  Virginia   22314 

Library  2 

Naval  Postgraduate  School 
Monterey,  California  93940 

Dean  of  Research,  Code  023  2 

Naval  Postgraduate  School 
Monterey,  California  9  3940 

Professor  Richard  Franke  5 

Department  of  Mathematics 
Naval  Postgraduate  School 
Monterey,  California  9  3940 

Professor  Craig  Comstock  1 

Department  of  Mathematics 
Naval  Postgraduate  School 
Monterey,  California  93940 

Dr.  Richard  Lau  1 

Office  of  Naval  Research 
Pasadena,  California  91100 

Professor  Ladis  D.  Kovach  1 

Chairman,  Department  of  Mathematics 
Naval  Postgraduate  School 
Monterey,  California 

Naval  Electronics  Laboratory  Center 

271  Catalina  Blvd. 

Attn:   Code  220  1 

Code  5000  5 

Mr.  William  J.  Dejka  1 

Mr.  Norman  Tinklepaugh  1 

Mr.  Don  Eddington  1 

Mr.  David  Harrison  1 

Mr.  Dwight  Wilcox  1 

San  Diego,  California  92152 


44  - 


y 1 67731 


DUDLEY  KNOX  LIBRARY  -  RESEARCH  REPORTS 

5  6853  01060525  6 


